Splittable blockchain based ownership verification

ABSTRACT

A method may include splitting an original token into a first sub-token and a second sub-token, generating a first hash value of the first sub-token and a first randomness value, and generating a second hash value of the second sub-token and a second randomness value. The method may also include evaluating an NIZKP regarding the split, and sampling first and second signature keys and verification keys associated with the first and second sub-tokens, respectively. The method may additionally include generating first and second signed values of concatenations of the first and second hash values and the first and second verification keys, respectively, and signed using an initial signature key of a current owner of the original token. The method may additionally include sending the NIZKP, the first and second hash values, the first and second signed values, and the first and second verification keys to the blockchain.

FIELD

Embodiments of the present disclosure relate to blockchain basedownership verification.

BACKGROUND

Verifying ownership can be a difficult process. For example, someoneseeking to verify that they are the owner of some asset may be requiredto provide various components or involve a third party to verify theirownership. However, in many circumstances, such ownership verificationhas been unchanged for many years.

SUMMARY

One or more embodiments of the present disclosure may include a methodthat includes obtaining, by a first entity, a verification key from asecond entity to which an asset is to be transferred. The method mayalso include proving to an administrator of a blockchain that the firstentity is a current owner of the asset, the blockchain hosting a tokenassociated with the asset. The method may additionally include providingan updated randomness value and the token to the second entity. Themethod may also include sending an updated hash value of the token andthe updated randomness, a signed indication of the transfer of the assetfrom the first entity to the second entity, and the verification key ofthe second entity to an administrator of the blockchain.

One or more embodiments of the present disclosure may include a methodthat includes splitting an original token into a first sub-token and asecond sub-token, generating a first hash value of the first sub-tokenand a first randomness value, and generating a second hash value of thesecond sub-token and a second randomness value. The method may alsoinclude evaluating a non-interactive zero knowledge proof regarding thesplit of the original token into the first sub-token and the secondsub-token, and sampling a first signature key and first verification keyassociated with the first sub-token and a second signature key andsecond verification key associated with the second sub-token. The methodmay additionally include generating a first signed value of aconcatenation of the first hash value and the first verification key andsigned using an initial signature key of a current owner of the originaltoken, and generating a second signed value of a concatenation of thesecond hash value and the second verification key and signed using theinitial signature key of the current owner of the original token. Themethod may additionally include sending the non-interactive zeroknowledge proof, the first hash value, the first signed value, the firstverification key, the second hash value, the second signed value, andthe second verification key to an administrator of a blockchain forposting to the blockchain.

The object and advantages of the embodiments will be realized andachieved at least by the elements, features, and combinationsparticularly pointed out in the claims.

It is to be understood that both the foregoing general description andthe following detailed description are merely examples and explanatoryand are not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments will be described and explained with additionalspecificity and detail through the use of the accompanying drawings inwhich:

FIG. 1 is a diagram illustrating an example system which may utilize ablockchain to verify ownership of an asset;

FIG. 2 is a diagram illustrating an example system which may utilize ablockchain to verify ownership of an asset in which rights associatedwith ownership may be split;

FIG. 3 illustrates an example flowchart of an example method of issuinga token associated with an owned asset;

FIG. 4 illustrates an example flowchart of an example method oftransferring ownership of an asset;

FIG. 5 illustrates an example flowchart of an example method of provingcurrent ownership of an asset to an administrator of a blockchain;

FIG. 6 illustrates an example flowchart of an example method ofverifying ownership of an asset;

FIGS. 7A and 7B illustrate an example flowchart of an example method ofsplitting rights associated with ownership of an asset; and

FIG. 8 illustrates an example computing system.

DETAILED DESCRIPTION

The present disclosure relates to the use of blockchain technology toverify ownership of an asset. For example, an issuing entity may providean electronic token associated with ownership to an owner of an assetand may post a hash associated with the token for posting to theblockchain. For example, a county government office may issue a tokenassociated with ownership of real estate. The owner of the asset may bepermitted to transfer ownership of the asset without involving orincluding the issuing entity. For example, the owner may be able totransfer ownership of the real estate to a subsequent owner withoutinvolving the county government office. Instead, the original owner mayprove current ownership to the blockchain and may post a new entry in alist on the blockchain identifying new ownership of the asset. If averifier wants to verify whether or not an entity is the owner, theverifier is able to observe the most recent block on the list of theblockchain and compare it to information provided by the current owner(such as via a zero knowledge proof) to verify current ownership. Forexample, for a bank that wants to verify that the owner of the realestate is in fact the owner, the bank can verify the ownership based oninformation obtained from the owner and the blockchain without involvingthe county government office. Additionally, the verification informationis in a publicly reliable location such as the blockchain.

In these and other embodiments, a current owner may prove theirownership to an administrator of the blockchain prior to transferringownership. For example, a non-interactive zero knowledge proof (NIZKP)based on a randomness value associated with the current ownership andthe token may be used to prove to the administrator of the blockchainthat the user submitting the information is the current owner.Additionally or alternatively, a similar or comparable NIZKP may be usedto prove to the potential acquirer of the asset that the user offeringto transfer the asset is the current owner of the asset.

In some embodiments, the issuing entity may set up provision for thetoken to be split based on the rights associated with the token. Forexample, if the owned asset is a condominium, the issuing entity maypermit for the splitting of the token into individual days associatedwith possession of the condominium (such as a nightly rental). In theseand other embodiments, the individual components of the split token maybe a faithful decomposition of the original token. After splitting thetoken, the owner splitting the token may provide information for theblockchain to start new lists on the blockchain, with each sub-tokenhaving its own list on the blockchain with transferrable ownership ofthe sub-token. The list associated with the original token may also beinvalidated.

Certain embodiments of the present disclosure may provide improvementsover previous iterations of secure communications and ownershipvalidation/verification. For example, embodiments of the presentdisclosure may provide a more secure interaction between parties bypermitting limited exposure of information. In particular, a verifiermay be able to verify ownership of an asset in a reliable manner whilethe verifier does not have to necessarily have access to otherinformation regarding the ownership of the asset. Additionally, theissuing party may not be required to be involved in each successivetransfer of ownership and/or splitting of ownership rights of an asset.For example, the issuing entity may be completely offline duringsubsequent transactions. This may reduce the workload of the issuingentity while also providing privacy from the issuing entity.Additionally, embodiments of the present disclosure permits usingblockchain technology to facilitate the security and reliability of thepublic information that facilitates the verification of ownership andtransfer of assets. For example, the actual tokens and/or theirproperties may remain confidential to the blockchain using randomnessvalues. In some embodiments, a public key infrastructure is notnecessary as keys may be generated as transactions come up. In someembodiments, the users and/or tokens across transactions may beunlinkable (e.g., particular users may or may not be traceable tocertain transactions and/or tokens). Additionally, one or moreembodiments of the present disclosure may facilitate the splitting oftokens and/or associated aspects or rights of ownership of an assetwithout the involvement of an issuing entity and/or the privacy andsecurity of the blockchain.

One or more example embodiments are explained with reference to theaccompanying drawings.

FIG. 1 is a diagram illustrating an example system 100 which may utilizea blockchain 135 to verify ownership of an asset, in accordance with oneor more embodiments of the present disclosure. The system 100 mayinclude an issuing entity 110, a user A 120, a user B 121, and a user C122, an administrator of a blockchain 130, a list of the blockchain 135,and a verifier 140.

The issuing entity 110 may include any trusted authority or entity withauthority relative to the asset for which ownership is at issue. Forexample, if the asset is real estate or real property, the issuingentity 110 may include a county assessor's office, property tax office,records office, etc. As another example, if the asset is a vehicle, theissuing entity 110 may include a state department of motor vehicles(DMV), etc. In these and other embodiments, the issuing entity 110 maybe an entity in which it would be cumbersome to have the issuing entity110 involved with every transfer of ownership of the asset, or everyverification of ownership of the asset. Additionally or alternatively,it may be desirable to keep the issuing entity 110 unaware of thetransfers of ownership or verification of ownership for privacy reasons.

In operation, the issuing entity 110 may be configured to generate atoken (T₀) associated with an asset that is owned or is being acquiredin an initial transaction by the user A 120. An example of the issuingof the token may be described in greater detail with reference to FIG. 3. The issuing entity 110 may hold a signing/verification key pay(sk_(I), vk_(I)) where sk_(I) may represent the signature key (thesecret component) and vk_(I) may represent the verification key (thepublic component). The issuing entity may obtain a verification key ofthe user A 120, where the user A 120 may hold a signing/verification keypair (sk₀, vk₀). The issuing entity 110 may sample an initial randomnessvalue (r₀) and may provide the token (T₀) and the initial randomnessvalue (r₀) to the user A 120.

In some embodiments, the issuing entity 110 may provide informationindicative of ownership of the asset associated with the token (T₀) toan administrator of the blockchain 130. For example, the issuing entity110 may generate a hash value (h) of the token (T₀) and the initialrandomness value (r₀) that is provided to the administrator of theblockchain 130. Additionally or alternatively, the issuing entity 110may generate a signed value (σ) of a combination (e.g., a concatenation)of the hash value (h) and the verification key of the user A 120 (vk₀)that is signed using the signature key of the issuing entity 110(sk_(I)). Additionally or alternatively, the issuing entity 110 mayprovide the verification key of the user A 120 (vk₀) to theadministrator of the blockchain 130. For example, stated mathematically,h =Hash(T₀, r₀), where Hash may represent a hashing function, andσ=Sign(sk_(I), h∥vk₀).

The administrator of the blockchain 130 may include one or more entitieswith authority to post information to the blockchain 135. In someembodiments, the administrator of the blockchain 130 may includemultiple entities that follow a protocol such that after a certainnumber or percentage of administrators verify information, thatinformation is posted to the blockchain 135. In these and otherembodiments, one or more of the administrators may store a complete copyof the blockchain 135 such that the blockchain 135 may maintain publicintegrity.

In some embodiments, the administrator of the blockchain 130 may beconfigured to verify the information received from the issuing entity110 prior to posting the information to the blockchain 135. For example,the administrator of the blockchain 130 may verify the signed valuerelative to the verification key of the issuing entity 110 (vk_(I)) andthe concatenation of the hash value and the verification key of the userA 120. For example, stated mathematically, the administrator of theblockchain 130 may perform the operation VerifySign(vk_(I), σ, h∥vk₀)where VerifySign may be a verification of the signed value relative tothe verification keys.

After verification (e.g., if the VerifySign function succeeds), theadministrator of the blockchain 130 may post the hash value, the signedvalue, and/or the verification key of the user A 120 to the blockchain135 as an initial entry in a new list on the blockchain 135. Forexample, the values may be posted as a tuple 137 a to the blockchain135. The new list may be associated with the token (T₀). By using thehashed values and the signed values, the list may be associated with thetoken (T₀) without posting the token (T₀) to the blockchain 135. In thismanner, the token itself may be kept secure.

In some embodiments, the administrator of the blockchain 130 may postproof of one or more of the verifications performed by the administratorof the blockchain 130 to the blockchain 135. By posting the verificationto the blockchain, the overall integrity of transactions may be morereadily confirmed and observed. Additionally or alternatively, theadministrator of the blockchain 130 may discard the result of theverifications it has performed after performing the verifications. Forexample, by doing so, greater privacy may be maintained, and certainaspects of transactions and/or the number of transactions may be bettermasked.

In some embodiments, the user A 120 may desire to transfer the asset tothe user B 121. To transfer ownership, the blockchain 135 may be updatedto reflect the change in ownership. The user A 120 may prove ownershipto the administrator of the blockchain 130 such that the user A 120 ispermitted to post updated ownership information to the blockchain 135.An example of transferring ownership as reflected on the blockchain isdescribed with reference to FIG. 4 ; an example of proving ownership tothe administrator of the blockchain is described with reference to FIG.5 .

In some embodiments, to prove that the user A 120 is the current ownerof the asset associated with the token (T₀), the user A 120 may recallthe signature key (sk₀), the token (T), and the initial randomness value(r₀) from storage. The user A 120 may generate a proof to provide to theadministrator of the blockchain 130 that the user A 120 is the currentowner of the token (T). For example, the user A 120 may generate a zeroknowledge proof (such as an NIZK proof) of knowledge of T, and r. Statedmathematically, the user A 120 may generate the NIZK proof (π) of T, rsuch that

=Hash(T,

) where

may correspond to the last hash value on the blockchain 135 and

may correspond to the latest randomness value on the blockchain 135. Theuser A 120 may additionally generate a signed value (σ′) associated withthe NIZK proof (π), and the user A 120 may provide the signed value (σ′)and the NIZK proof (π) to the administrator of the blockchain 130 toprove ownership of the token (T). For example, mathematically derivingthe signed value (σ′) may include the evaluation of σ′=Sign(sk₀, s|π)where σ′ may be the signed value associated with the proof, Sign may bean encrypting/signing function in which a value is signed/encryptedusing a signature key, sk₀ may represent the signature key of the user A120, s may represent a hash (

) of the last block in the list of the blockchain 135 associated withthe token (T), and π may represent the proof of knowledge.

After receiving the proof and/or the signed value from the user A 120,the administrator of the blockchain 130 may verify the proof ofknowledge (π) of the user A 120 to validate that the user A 120 is thecurrent owner of the asset associated with the token (T₀). Additionallyor alternatively, the administrator of the blockchain may verify thesigned value. For example, stated mathematically, the administrator ofthe blockchain 130 may evaluate VerifySign(vk₀, σ′, s|π). Based on theproof of knowledge (π) and/or the VerifySign succeeding, theadministrator of the blockchain 130 may validate that the user A 120 isthe current owner of the asset associated with the token (T₀).

In some embodiments, the administrator of the blockchain 130 may permitthe user A 120 to provide information for a new block on the blockchain135 identifying new ownership of the asset associated with the token(T₀). For example, in transferring ownership to the user B 121, the userA 120 may obtain the verification key (vk₁) of the user B 121. The userA 120 may sample a second randomness value (r₁) and evaluate a secondhash value (h′) of the token (T₀) and the second randomness value (r₁).The user A 120 may generate a second signed value (σ″) of a combination(e.g., a concatenation) of the second hash value and the verificationkey of the user B 121 that is signed using the signature key of the userA 120. For example, stated mathematically, the user A 120 may evaluateh′=Hash(T₀, r₁) and may evaluate σ″=Sign(sk₀, h′∥vk₁).

After being verified as the current owner, the user A 120 may providethe administrator of the blockchain 130 with updated ownershipinformation associated with the user B 121. For example, the user A 120may provide the second hash value (h′), the second signed value (σ″),and the verification key of the user B 121 as the new ownershipinformation to be posted to the blockchain 135 as the new latestownership information associated with the token (T₀). The administratorof the blockchain 130 may verify that user A 120 is the current owner(as described above), and may verify the signature of the newlysubmitted ownership information. For example, the administrator of theblockchain 130 may evaluate VerifySign(vk₀, σ′, h′∥vk₁) and based on theevaluation succeeding, may append a tuple of (h′, σ″, vk₁) to theblockchain 135 as the tuple 137 b.

A similar process may follow if the user B 121 seeks to transfer theownership of the asset and the associated token (T₀) to the user C 122.For example, the user B 121 may prove to the administrator of theblockchain 130 that the user B 121 is the current owner of the token(T₀) and may provide updated ownership information identifying the userC 122 as the new owner (e.g., using the verification signature of theuser C 122 and providing the user C 122 with the newly sampledrandomness value). In these and other embodiments, it is the user withthe information associated with the latest posting to the blockchain 135(e.g., with the tuple 137 n) that may be verified as the current owner.An example of validating ownership to a verifier may be described withgreater detail in reference to FIG. 6 .

In some embodiments, the verifier 140 may seek to validate that a userpurporting to be the current owner of the asset associated with thetoken (T₀) is the current owner. For example, the user B 121 may seek toutilize real estate as collateral for a loan and a bank may seek tovalidate that user B 121 is the owner. The verifier 140 may include anyentity, user, device, system, etc. seeking to validate that a party hasknowledge of one or more properties associated with the token (T₀), suchas proof of ownership by showing knowledge of the randomness value andthe token. The one or more properties may be proved using a predicate(P), which may represent a function that operates on the token to yielda true or false (e.g., 1 or 0) result. In a simplest form, the predicatemay be set as 1 or true by the current owner of the token by default,indicating that as long as the token and/or randomness value correspondsto the latest posting to the list of the blockchain 135, theverification will be confirmed. Additionally or alternatively, anotherproperty of the token (T₀) and/or the associated asset may be used. Insuch a manner, a specific aspect of the token (To₀) and/or theassociated asset may be verified. For example, the predicate (P) may beused to prove that a real estate property has water rights, or that acondominium has pool access, etc. Additionally or alternatively, alimited subset of information may be disclosed to the verifier 140, forexample, information based on the predicate without any additionalinformation, providing increased privacy.

The process of validating ownership to the verifier 140 by a user (e.g.,the user B 121) may be a similar or comparable process to that used toprove ownership to the administrator of the blockchain 130, with someminor variation. In some embodiments, the verifier 140 may provide theuser B 121 with a random value (v) to facilitate verification. By way ofexample, the user B 121 may generate a proof of knowledge of the token(T₀) and the latest randomness value (r₁ in this example) and thepredicate. The user B 121 may additionally generate an additional signedvalue associated with the proof of knowledge and the random value (v)from the verifier 140. For example, stated mathematically, the user B121 may generate a NIZK proof (π) of the token (T₀) and the randomnessvalue (r₁) such that h′=Hash(T₀, r₁) and P(T₀)=1, where P( . . . )represents the predicate function. As another example, statedmathematically, the user B 121 may generate the additional signed valueσ′″=Sign(sk₀, v|π). In these and other embodiments, the user B 121 mayprovide the hash value h′, the proof of knowledge (π), and theadditional signed value (σ′″) to the verifier 140.

To validate ownership, the verifier 140 may use the hash value h′ toquery the blockchain 135 for the latest hash value on the blockchain135. If the query fails (e.g., because the user B 121 alreadytransferred the asset and associated token to the user C 122), theverifier 140 may abort the validation. If the query succeeds, theverifier 140 may verify the proof of knowledge (π) of the user B 121.Additionally or alternatively, the verifier 140 may verify the signedvalue. For example, stated mathematically, the verifier 140 may evaluateVerifySign(vk₁, σ′″, v|π). Based on the proof of knowledge (π) and/orthe VerifySign succeeding, the verifier 140 may validate that the user B121 is the owner of the asset associated with the token (T₀) and/or mayvalidate that the predicate P( . . . ) is verified.

Modifications, additions, or omissions may be made to the system 100without departing from the scope of the disclosure. For example, thedesignations of different elements in the manner described is meant tohelp explain concepts described herein and is not limiting. Further, thesystem 100 may include any number of other elements or may beimplemented within other systems or contexts than those described. Forexample, the system 100 may include any number of users between whichthe token may be passed. As another example, there may be any number ofadministrators providing input to, and/or controlling the blockchain135.

FIG. 2 is a diagram illustrating an example system 200 which may utilizea blockchain 235 to verify ownership of an asset in which rightsassociated with ownership may be split, in accordance with one or moreembodiment of the present disclosure. The system 200 may be similar orcomparable to the system 100 of FIG. 1 . For example, the issuing entity210 may be similar or comparable to the issuing entity 110 of FIG. 1 ;the user A 220, user B 221, and user C 222 may be similar or comparableto the user A 120, user B 121, and user C 122 of FIG. 1 ; theadministrator of the blockchain 230 may be similar or comparable to theadministrator of the blockchain 130 of FIG. 1 ; the blockchain 235 maybe similar or comparable to the blockchain 135 of FIG. 1 ; and/or theverifier 240 may be similar or comparable to the verifier 140 of FIG. 1.

In operation, the issuing entity 210 may issue the token T₀ in a similaror comparable manner to that described with reference to FIG. 1 . Toaccommodate the splitting of the token, the issuing entity 210 mayprovide rules, policies, or other information directing the manner inwhich the token (T₀) may be divided. For example, for real estate, theinformation may describe which rights of ownership may be divided fromeach other (e.g., access to a community pool, access to a dwelling,access to a garage, etc.), periods of time within which the rights maybe separated (e.g., weekly, nightly, and/or hourly occupation, etc.), orother manners in which the rights may be divided. As another example,for ownership of a vehicle like an electric car, the information maydescribe periods of time within which the rights may be separated (e.g.,minutes or hours during a day, days, or weeks of use, etc.), portions ofrights that may be divided (e.g., occupancy of a front seat, occupancyof a back seat, etc.), etc. In these and other embodiments, theinformation regarding the splitting or dividing of the token may includethe smallest unit of time for which divisible possession or use isdesirable (such as nightly for an apartment rental, or hourly forvehicle use, etc.).

In some embodiments, the user A 220 may desire to split rights ofownership of the asset associated with the token (T₀) into two separatesub-tokens (T₁) and (T₂). For example, the user A 220 may desire toseparate out one week of occupancy of his condominium (T₂) whileremaining occupancy for the remainder of the time (T₁). The combinationof the two sub-tokens (T₁) and (T₂) may represent all of the rights ofownership of the asset associated with the token (T₀), or stated anotherway, the sub-tokens (T₁) and (T₂) may represent a faithful decompositionof the original token (T₀). An example of splitting the token (T₀) intothe sub-tokens (T₁) and (T₂) may be described with reference to FIGS. 7Aand 7B.

In some embodiments, to split the token (T₀), the user A 220 may beconceptually similar to the user A 220 acting as the issuing entity toissue two new sub-tokens (T₁) and (T₂). For example, the user A 220 maysample two new randomness values (r₁₀, r₂₀) and generate two new tokens(T₁, T₂). The user A 220 may derive the hashes h₁=Hash(T₁, r₁₀) andh₂=Hash(T₂, r₂₀). The user A 220 may prove to the administrator of theblockchain 230 that the user A 220 is the current owner of the latestblock in the blockchain 235 (e.g., is the owner associated with thetuple 237 b).

In some embodiments, the user A 220 may generate a proof of knowledge onthe last hash (

) value associated with the original token (T₀) and the two new hashvalues. For example, the user A 220 may generate a NIZK on the statement“There exists T₀, r₀, r₁₀, r₂₀:

=Hash(T₀, r₀) and h₁=Hash(T₁, r₁₀) and h₂=Hash(T₂, r₂₀) and (T₁, T₂) isa faithful decomposition of T₀.”

In some embodiments, the user A 220 may generate a signed value for eachof the generated sub-tokens using a new signature key pair for each ofthe new sub-tokens and signed using a signature key of the user A 220associated with the original token (T₀). For example, the user A 220 maysample (sk₁₀, vk₁₀) and (sk₂₀, vk₂₀) as being associated with the newsub-tokens (T₁) and (T₂), respectively. An example of generating thesigned values, stated mathematically, may include σ₁=Sign(sk, h₁∥vk₁₀)and σ₂=Sign(sk, h₂∥vk₂₀) where σ₁ and σ₂ may represent the signedvalues, and sk may represent the signature key of the user A 220associated with the original token (T₀). In some embodiments, the user A220 may retain ownership of one of the tokens, and may utilize the samesignature key for a retained sub-token (e.g., the user A 220 maymaintain sk¹⁰ as the same value as sk).

In some embodiments, the user A 220 may provide the owners of thesub-tokens with the signature keys generated by the user A 220 asassociated with the new sub-tokens. For example, following the exampleillustrated in FIG. 2 when transferring the token T₁ to the user B 221and the token T₂ to the user C 222, the user A 220 may provide the userB 221 with the token T₁ along with the randomness value r₁₀ and thesignature key sk¹⁰. Similarly, the user A 220 may provide the user C 222with the token T₂ along with the randomness value r₂₀ and the signaturekey sk₂₀.

The user A 220 may provide the administrator of the blockchain 230 withthe updated information regarding ownership. For example, the user A 220may send the tuples (h₁, σ₁, vk₁₀) and (h₂, σ₂, vk₂₀) to theadministrator of the blockchain 230. The administrator of the blockchain230 may verify the signature values and the proof of knowledge from theuser A 220. Based on both being verified, the administrator of theblockchain 230 may generate two new lists on the blockchain 235associated with each of the two new sub-tokens (T₁) and (T₂). Forexample, the blockchain 235 may include a first list 235 b with aninitial tuple 238 a and a second list 235 c with an initial tuple 239 a.In some embodiments, the administrator of the blockchain 230 may cap,cancel, block, or otherwise prevent any further additions to theoriginal list 235 a of the blockchain 235.

Each of the sub-tokens (T₁) and (T₂) may be independently transferredand/or verified as described above with reference to FIG. 1 .Additionally or alternatively, if the information regarding the tokensindicates that the tokens may be further subdivided, a later owner ofthe sub-tokens may further split one or more of the tokens. In someembodiments, a given token may be split into multiple tokens and is notlimited to being split into two tokens as illustrated in the example ofFIG. 2 . Rather, FIG. 2 serves as an illustrative example of theprinciples of the present disclosure.

Modifications, additions, or omissions may be made to the system 200without departing from the scope of the disclosure. For example, thedesignations of different elements in the manner described is meant tohelp explain concepts described herein and is not limiting. Further, thesystem 200 may include any number of other elements or may beimplemented within other systems or contexts than those described. Forexample, the system 200 may include any number of users between whichthe token may be split. As another example, there may be any number ofadministrators providing input to, and/or controlling the blockchain235.

FIG. 3 illustrates an example flowchart of an example method 300 ofissuing a token associated with an owned asset, in accordance with oneor more embodiments of the present disclosure. One or more operations ofthe method 300 may be performed by a system or device, or combinationsthereof, such as the system 100, the issuing entity 110, the user A 120,the user B 121, the user C 122, the administrator of the blockchain 130,and/or the verifier 140 of FIG. 1 and/or the system 100, the issuingentity 210, the user A 220, the user B 221, the user C 222, theadministrator of the blockchain 230, and/or the verifier 240 of FIG. 2 .Although illustrated as discrete blocks, various blocks of the method300 may be divided into additional blocks, combined into fewer blocks,or eliminated, depending on the desired implementation.

At block 310, a verification key of an entity to which a token is to beassigned is obtained. For example, an issuing entity may receive theverification key from a user who is the owner of an asset. In these andother embodiments, the entity that is the owner may derive a pair ofsignature keys (e.g., (sk₀, vk₀)), and the verification key of the pair(vk₀) may be provided to the issuing entity.

At block 320, a token may be generated. For example, the issuing entitymay generate the token (T₀) associated with the asset owned by theentity/user.

At block 330, an initial randomness value associated with the token maybe sampled. For example, the issuing entity may generate the initialrandomness value (r₀) by sampling the value from the set of realnumbers.

At block 340, the token and the initial randomness value may be sent tothe entity. For example, the issuing entity may provide the token (T₀)and the initial randomness value (r₀) to the user that is the owner ofthe asset for which the token is issued.

At block 350, a hash value of the token and the initial randomnessvalue, a signed indication of the ownership of the asset, and theverification key of the first entity may be sent to the blockchain. Forexample, the issuing entity may generate the hashed value (e.g.,h=Hash(T, r)) and the signed indication of the ownership of the asset(e.g., σ=Sign(sk_(I),h∥vk₀)) to provide to the administrator of theblockchain along with the verification key of the first entity.

At block 360, verification may be performed on the received informationprior to posting the information to the blockchain. For example, anadministrator of the blockchain may verify the signed value prior toposting the tuple of the hashed value, the signed indication ofownership, and the verification key of the first entity to theblockchain.

At block 370, a new list may be started on the blockchain as associatedwith the token. For example, the new list may reflect a history ofownership of the asset as identified by holder of the token, with thelast posting in the new list reflecting the current owner of the token(and by implication, the associated asset).

Modifications, additions, or omissions may be made to the method 300without departing from the scope of the disclosure. For example, theoperations of the method 300 may be implemented in differing order.Additionally or alternatively, two or more operations may be performedat the same time. Furthermore, the outlined operations and actions areprovided as examples, and some of the operations and actions may beoptional, combined into fewer operations and actions, or expanded intoadditional operations and actions without detracting from the essence ofthe disclosed embodiments.

FIG. 4 illustrates an example flowchart of an example method 400 oftransferring ownership of an asset from a first entity to a secondentity, in accordance with one or more embodiments of the presentdisclosure. One or more operations of the method 400 may be performed bya system or device, or combinations thereof, such as the system 100, theissuing entity 110, the user A 120, the user B 121, the user C 122, theadministrator of the blockchain 130, and/or the verifier 140 of FIG. 1and/or the system 100, the issuing entity 210, the user A 220, the userB 221, the user C 222, the administrator of the blockchain 230, and/orthe verifier 240 of FIG. 2 . Although illustrated as discrete blocks,various blocks of the method 400 may be divided into additional blocks,combined into fewer blocks, or eliminated, depending on the desiredimplementation.

At block 410, a verification key may be obtained from a second entity.For example, a first user that owns an asset and is transferring anasset to a second user may obtain the verification key of the seconduser.

At block 420, the first entity may prove to an administrator of theblockchain that the first entity is the current owner of the asset. Forexample, the first user may generate a NIZK proof of knowledge of thetoken and the randomness value associated with the last entry in theblockchain.

At block 430, the first entity may provide an updated randomness valueand the token to the second entity. For example, the first entity maysample a new random value as the updated randomness value to beassociated with the token and the new owner, the second entity.

At block 440, the first entity may send an updated hash value, a signedverification of the transfer, and the verification of the second key tothe administrator of the blockchain. For example, the first entity mayderive a hash value of the token and the updated randomness value as theupdated hash value. Additionally or alternatively, the signedverification of the transfer may include a combination (e.g., aconcatenation) of the updated hash value and the verification key of thesecond entity (e.g., the new owner), signed by the signature key of thefirst entity (e.g., the original owner).

In some embodiments, in addition to or alternatively to the proof at theblock 420, the first entity may provide a proof of knowledge of thetoken, the initial randomness value (or the most recently-postedrandomness value to the block chain), and the updated randomness valuesuch that the latest hash posted on the blockchain is the same as thehash provided by the first entity (e.g., the hash of the token and theinitial randomness value (or the most recently-posted randomness valueto the block chain)) as well as the new hash value of the token and theupdated randomness value. In proving the knowledge, the first entity mayprovide the proof as a function of the latest hash in the blockchain assigned by the signature key of the first entity.

At block 450, the administrator of the blockchain may performverification of one or more pieces of information prior to posting a newblock to the blockchain. For example, the administrator of theblockchain may verify that the first entity has knowledge of the tokenand initial randomness value by verifying the proof of knowledge of theblock 420. As another example, the administrator of the block chain mayverify the proof of knowledge of the block 440. As a further example,the administrator of the blockchain may verify the signed verificationof the transfer of ownership of the block 440.

At block 460, the administrator of the blockchain may post the updatedhash value, the signed indication of the transfer, and/or theverification key of the second entity to the blockchain. For example, atuple of the updated hash value, the signed indication of the transfer,and/or the verification key of the second entity may be posted as a newlatest block in the list on the blockchain associated with the token. Byadding the new block, the ownership information reflects the new owneras the last block in the list is now associated with the verificationkey of the second entity and the updated randomness value that is inpossession of the second entity.

Modifications, additions, or omissions may be made to the method 400without departing from the scope of the disclosure. For example, theoperations of the method 400 may be implemented in differing order.Additionally or alternatively, two or more operations may be performedat the same time. Furthermore, the outlined operations and actions areprovided as examples, and some of the operations and actions may beoptional, combined into fewer operations and actions, or expanded intoadditional operations and actions without detracting from the essence ofthe disclosed embodiments.

FIG. 5 illustrates an example flowchart of an example method 500 ofproving current ownership of an asset to an administrator of ablockchain, in accordance with one or more embodiments of the presentdisclosure. For example, the method 500 may be an example of or anexpansion of the block 420 of FIG. 4 . One or more operations of themethod 500 may be performed by a system or device, or combinationsthereof, such as the system 100, the issuing entity 110, the user A 120,the user B 121, the user C 122, the administrator of the blockchain 130,and/or the verifier 140 of FIG. 1 and/or the system 100, the issuingentity 210, the user A 220, the user B 221, the user C 222, theadministrator of the blockchain 230, and/or the verifier 240 of FIG. 2 .Although illustrated as discrete blocks, various blocks of the method500 may be divided into additional blocks, combined into fewer blocks,or eliminated, depending on the desired implementation.

At block 510, a signature key of the first entity, a token, and aninitial randomness value may be recalled from a storage location by thefirst entity. For example, the first entity may store its own signaturekey, the token, and the initial randomness value to be used to proveownership of the asset associated with the token and/or to convey theasset to another entity.

At block 520, a non-interactive zero knowledge proof (NIZKP) may beevaluated based on the token and the initial randomness value. Forexample, the NIZKP may prove knowledge of the token (T) and the initialrandomness value (r) such that a hash of the two matches the hash of thelatest entry on the blockchain.

At block 530, a signed value of a combination of the NIZKP of the block520 and a last block in the blockchain may be derived and signed usingthe signature key of the first entity. For example, the first entity mayderive the signed value by performing the operation σ′=Sign(sk₀, s|π).

At block 540, the NIZKP of the block 520 and the signed value of theblock 530 may be sent to the administrator of the blockchain.

At block 550, a verification may be performed on the informationprovided to the administrator of the blockchain prior to posting to theblockchain. For example, the administrator of the blockchain may verifythe NIZKP evaluates to an affirmative value. Based on the informationbeing verified, e.g., the NIZKP and signed value indicating the firstentity has knowledge of the token and the initial randomness value, theadministrator of the blockchain may identify the first entity as beingthe current owner of the token and the associated asset.

In some embodiments, the administrator of the blockchain may post theverification itself, the NIZKP, or other information related to theverification to the blockchain such that the verification is observableand checkable upon the blockchain. Additionally or alternatively, theadministrator of the blockchain may discard the results and/or otherinformation related to performing the verification after theverification has been performed.

Modifications, additions, or omissions may be made to the method 500without departing from the scope of the disclosure. For example, theoperations of the method 500 may be implemented in differing order.Additionally or alternatively, two or more operations may be performedat the same time. Furthermore, the outlined operations and actions areprovided as examples, and some of the operations and actions may beoptional, combined into fewer operations and actions, or expanded intoadditional operations and actions without detracting from the essence ofthe disclosed embodiments.

FIG. 6 illustrates an example flowchart of an example method 600 ofverifying ownership of an asset, in accordance with one or moreembodiments of the present disclosure. One or more operations of themethod 600 may be performed by a system or device, or combinationsthereof, such as the system 100, the issuing entity 110, the user A 120,the user B 121, the user C 122, the administrator of the blockchain 130,and/or the verifier 140 of FIG. 1 and/or the system 100, the issuingentity 210, the user A 220, the user B 221, the user C 222, theadministrator of the blockchain 230, and/or the verifier 240 of FIG. 2 .Although illustrated as discrete blocks, various blocks of the method600 may be divided into additional blocks, combined into fewer blocks,or eliminated, depending on the desired implementation.

At block 610, a signing key of a first entity, a token, and an initialrandomness value may be recalled from storage. For example, the firstentity may store one or more of such values to facilitate verificationof ownership.

At block 620, an NIZKP of the token and the initial randomness value maybe evaluated. For example, the first entity may evaluate (π) in theNIZKP that the first entity has knowledge of T, r such that

=Hash(T, r).

At block 630, it may be validated that a predicate associated with thetoken resolves affirmatively. For example, the NIZKP of the block 620 asderived by the first entity may include proof that a predicateassociated with the token is also provably true. For example, the NIZKPmay include proof that P(T)=1.

At block 640, a signed value may be derived that includes a combinationof the non-interactive zero knowledge proof (NIZKP) of the block 620and/or 630, a last block in the blockchain, and/or a randomly sampledvalue provided by the verifier. In these and other embodiments, thesigned value may be signed using the signature key of the first entity.For example, the first entity may receive a randomly sampled value fromthe verifier (v) that may be used in generating the signed value. Forexample, stated mathematically, the first entity may generate the signedvalue σ′″=Sign(sk₀, v|π).

At block 650, the first entity may send an initial hash value of thetoken and the initial randomness value, the NIZKP, and the signed valueto the verifier.

At block 660, the verifier may query the blockchain for a latest hashvalue associated with the token. For example, the verifier may use theinitial hash value received from the first entity to query theblockchain 135 for the latest hash value on the blockchain 135. If thequery fails, the verifier may abort the validation.

At block 670, the verifier may verify the proof of knowledge (e.g., theNIZKP of the blocks 620 and/or 630) and/or the signed value. Forexample, stated mathematically, the verifier may evaluateVerifySign(vk₁,σ′″,v|π). Based on the proof of knowledge (e.g., π)and/or the VerifySign succeeding, the verifier may validate that thefirst entity is the owner of the asset associated with the token (To)and/or may validate that the predicate of the block 630 is verified.

Modifications, additions, or omissions may be made to the method 600without departing from the scope of the disclosure. For example, theoperations of the method 600 may be implemented in differing order.Additionally or alternatively, two or more operations may be performedat the same time. Furthermore, the outlined operations and actions areprovided as examples, and some of the operations and actions may beoptional, combined into fewer operations and actions, or expanded intoadditional operations and actions without detracting from the essence ofthe disclosed embodiments.

FIGS. 7A and 7B illustrate an example flowchart of an example method 700of splitting rights associated with ownership of an asset, in accordancewith one or more embodiments of the present disclosure. One or moreoperations of the method 700 may be performed by a system or device, orcombinations thereof, such as the system 100, the issuing entity 110,the user A 120, the user B 121, the user C 122, the administrator of theblockchain 130, and/or the verifier 140 of FIG. 1 and/or the system 100,the issuing entity 210, the user A 220, the user B 221, the user C 222,the administrator of the blockchain 230, and/or the verifier 240 of FIG.2 . Although illustrated as discrete blocks, various blocks of themethod 700 may be divided into additional blocks, combined into fewerblocks, or eliminated, depending on the desired implementation.

At block 705, an original token may be split into a first sub-token anda second sub-token. For example, a first user that owns a token maysplit the original token into the sub-tokens based on information,rules, policies, etc. promulgated by an issuing entity that issued theoriginal token (or the original predecessor to the original token).

At block 710, a first hash value may be generated that hashes acombination (e.g., a concatenation) of the first sub-token and a firstrandomness value. For example, the first user may sample the firstrandomness value as being associated with the first sub-token.

At block 715, a second hash value may be generated that hashes acombination (e.g., a concatenation) of the second sub-token and a secondrandomness value. For example, the first user may sample the secondrandomness value as being associated with the second sub-token.

At block 720, a proof of knowledge (e.g., an NIZKP) may be evaluatedregarding the split of the original token into the first sub-token andthe second sub-token. For example, the NIZKP may prove that the firstsub-token and the second sub-token are a faithful decomposition of theoriginal token.

At block 725, a first signature key and first verification keyassociated with the first sub-token may be sampled by the first user.Additionally or alternatively, a second signature key and secondverification key associated with the second sub-token may be sampled bythe first user.

At block 730, a first signed value may be generated of a concatenationof the first hash value and the first verification key that is signedusing an initial signature key of a current owner of the original token(e.g., the first user).

Turning to the FIG. 7B, at block 735, a second signed value may begenerated of a concatenation of the second hash value and the secondverification key that is signed using the initial signature key of thecurrent owner of the original token (e.g., the first user).

At block 740, the NIZKP of the block 720, the first hash value of theblock 710, the first signed value of the block 730, the firstverification key of the block 725, the second hash value of the block715, the second signed value of the 735, and the second verification keyof the block 725 may be sent to an administrator of the blockchain. Forexample, a proof of ownership and/or information for new lists for splitownership may be provided to the administrator of the blockchain forposting to the blockchain.

At block 745, verification may be performed by the administrator of theblockchain prior to posting one or more pieces of the information of theblock 740 to the blockchain. For example, the administrator may verifythat the first user is the current owner of the token. As anotherexample, the administrator of the blockchain may verify that the firstand/or second signed values are properly signed and/or that the NIZKPevaluate affirmatively.

At block 750, an original list on the blockchain associated with theoriginal token may be invalidated. For example, a capping entry may beplaced on the original list on the blockchain. As another example, anyother notification or posting that may signify that the original list isno longer viable or reflective of current ownership of the token may beused.

At block 755, a new list may be started on the blockchain associatedwith the first sub-token. For example, the new list associated with thefirst sub-token may post a tuple of the first hashed value, the firstsigned value, and the first verification key.

At block 760, another new list may be started on the blockchainassociated with the second sub-token. For example, the new listassociated with the second sub-token may post a tuple of the secondhashed value, the second signed value, and the second verification key.

At block 765, the first sub-token may be split into multiple additionalsub-tokens. For example, the first sub-token may be split into fourth,fifth, and sixth sub-tokens consistent with the information, rules,policies, etc. promulgated by the issuing entity. After splitting thefirst sub-token, the invalidation of the new list associated with thefirst sub-token and the generation of new lists associated with thefourth, fifth, and sixth sub-tokens may follow similar or comparableoperations to those described above with reference to splitting theoriginal token into the first and second sub-tokens.

Additionally or alternatively, verification of ownership and/ortransference of the first sub-token and/or the second sub-token mayoccur in a similar manner described in the present disclosure, such asin FIGS. 3-6 .

Modifications, additions, or omissions may be made to the method 700without departing from the scope of the disclosure. For example, theoperations of the method 700 may be implemented in differing order.Additionally or alternatively, two or more operations may be performedat the same time. Furthermore, the outlined operations and actions areprovided as examples, and some of the operations and actions may beoptional, combined into fewer operations and actions, or expanded intoadditional operations and actions without detracting from the essence ofthe disclosed embodiments.

FIG. 8 illustrates an example computing system 800, according to atleast one embodiment described in the present disclosure. The computingsystem 800 may include a processor 810, a memory 820, a data storage830, and/or a communication unit 840, which all may be communicativelycoupled. Any or all of the system 100 of FIG. 1 and/or 200 of FIG. 2 maybe implemented as a computing system consistent with the computingsystem 800, including the issuing entity 110, the user A 120, the user B121, the user C 122, the administrator of the blockchain 130, and/or theverifier 140 of FIG. 1 and/or the issuing entity 210, the user A 220,the user B 221, the user C 222, the administrator of the blockchain 230,and/or the verifier 240 of FIG. 2 .

Generally, the processor 810 may include any computer, computing entity,or processing device including various computer hardware or softwaremodules and may be configured to execute instructions stored on anyapplicable computer-readable storage media. For example, the processor810 may include a microprocessor, a microcontroller, a digital signalprocessor (DSP), an application-specific integrated circuit (ASIC), aField-Programmable Gate Array (FPGA), or any other digital or analogcircuitry configured to interpret and/or to execute program instructionsand/or to process data.

Although illustrated as a single processor in FIG. 8 , it is understoodthat the processor 810 may include any number of processors distributedacross any number of network or physical locations that are configuredto perform individually or collectively any number of operationsdescribed in the present disclosure. In some embodiments, the processor810 may interpret and/or execute program instructions and/or processdata stored in the memory 820, the data storage 830, or the memory 820and the data storage 830. In some embodiments, the processor 810 mayfetch program instructions from the data storage 830 and load theprogram instructions into the memory 820.

After the program instructions are loaded into the memory 820, theprocessor 810 may execute the program instructions, such as instructionsto perform any of the methods 300, 400, 500, 600, and/or 700 of FIGS.3-7B, respectively. For example, the processor 810 may obtaininstructions regarding issuing a token associated with an asset,verifying ownership of the token, posting information to the blockchain,splitting the token, etc.

The memory 820 and the data storage 830 may include computer-readablestorage media or one or more computer-readable storage mediums forcarrying or having computer-executable instructions or data structuresstored thereon. Such computer-readable storage media may be anyavailable media that may be accessed by a computer, such as theprocessor 810. For example, the memory 820 and/or the data storage 830may store a complete copy of a blockchain (such as the blockchain 135 ofFIG. 1 ). In some embodiments, the computing system 800 may or may notinclude either of the memory 820 and the data storage 830.

By way of example, and not limitation, such computer-readable storagemedia may include non-transitory computer-readable storage mediaincluding Random Access Memory (RAM), Read-Only Memory (ROM),Electrically Erasable Programmable Read-Only Memory (EEPROM), CompactDisc Read-Only Memory (CD-ROM) or other optical disk storage, magneticdisk storage or other magnetic storage devices, flash memory devices(e.g., solid state memory devices), or any other storage medium whichmay be used to carry or store desired program code in the form ofcomputer-executable instructions or data structures. Combinations of theabove may also be included within the scope of computer-readable storagemedia. Computer-executable instructions may include, for example,instructions and data configured to cause the processor 810 to perform acertain operation or group of operations.

The communication unit 840 may include any component, device, system, orcombination thereof that is configured to transmit or receiveinformation over a network. In some embodiments, the communication unit840 may communicate with other devices at other locations, the samelocation, or even other components within the same system. For example,the communication unit 840 may include a modem, a network card (wirelessor wired), an optical communication device, an infrared communicationdevice, a wireless communication device (such as an antenna), and/orchipset (such as a Bluetooth device, an 802.6 device (e.g., MetropolitanArea Network (MAN)), a WiFi device, a WiMax device, cellularcommunication facilities, or others), and/or the like. The communicationunit 840 may permit data to be exchanged with a network and/or any otherdevices or systems described in the present disclosure. For example, thecommunication unit 840 may allow the system 800 to communicate withother systems, such as computing devices and/or other networks.

One skill in the art, after reviewing this disclosure, may recognizethat modifications, additions, or omissions may be made to the system800 without departing from the scope of the present disclosure. Forexample, the system 800 may include more or fewer components than thoseexplicitly illustrated and described.

The foregoing disclosure is not intended to limit the present disclosureto the precise forms or particular fields of use disclosed. As such, itis contemplated that various alternate embodiments and/or modificationsto the present disclosure, whether explicitly described or impliedherein, are possible in light of the disclosure. Having thus describedembodiments of the present disclosure, it may be recognized that changesmay be made in form and detail without departing from the scope of thepresent disclosure. Thus, the present disclosure is limited only by theclaims.

In some embodiments, the different components, modules, engines, andservices described herein may be implemented as objects or processesthat execute on a computing system (e.g., as separate threads). Whilesome of the systems and processes described herein are generallydescribed as being implemented in software (stored on and/or executed bygeneral purpose hardware), specific hardware implementations or acombination of software and specific hardware implementations are alsopossible and contemplated.

Terms used herein and especially in the appended claims (e.g., bodies ofthe appended claims) are generally intended as “open” terms (e.g., theterm “including” should be interpreted as “including, but not limitedto,” the term “having” should be interpreted as “having at least,” theterm “includes” should be interpreted as “includes, but is not limitedto,” etc.).

Additionally, if a specific number of an introduced claim recitation isintended, such an intent will be explicitly recited in the claim, and inthe absence of such recitation no such intent is present. For example,as an aid to understanding, the following appended claims may containusage of the introductory phrases “at least one” and “one or more” tointroduce claim recitations. However, the use of such phrases should notbe construed to imply that the introduction of a claim recitation by theindefinite articles “a” or “an” limits any particular claim containingsuch introduced claim recitation to embodiments containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should be interpreted to mean “at least one”or “one or more”); the same holds true for the use of definite articlesused to introduce claim recitations.

In addition, even if a specific number of an introduced claim recitationis explicitly recited, those skilled in the art will recognize that suchrecitation should be interpreted to mean at least the recited number(e.g., the bare recitation of “two recitations,” without othermodifiers, means at least two recitations, or two or more recitations).Furthermore, in those instances where a convention analogous to “atleast one of A, B, and C, etc.” or “one or more of A, B, and C, etc.” isused, in general such a construction is intended to include A alone, Balone, C alone, A and B together, A and C together, B and C together, orA, B, and C together, etc. For example, the use of the term “and/or” isintended to be construed in this manner.

Further, any disjunctive word or phrase presenting two or morealternative terms, whether in the description, claims, or drawings,should be understood to contemplate the possibilities of including oneof the terms, either of the terms, or both terms. For example, thephrase “A or B” should be understood to include the possibilities of “A”or “B” or “A and B.”

However, the use of such phrases should not be construed to imply thatthe introduction of a claim recitation by the indefinite articles “a” or“an” limits any particular claim containing such introduced claimrecitation to embodiments containing only one such recitation, even whenthe same claim includes the introductory phrases “one or more” or “atleast one” and indefinite articles such as “a” or “an” (e.g., “a” and/or“an” should be interpreted to mean “at least one” or “one or more”); thesame holds true for the use of definite articles used to introduce claimrecitations.

Additionally, the use of the terms “first,” “second,” “third,” etc. arenot necessarily used herein to connote a specific order. Generally, theterms “first,” “second,” “third,” etc., are used to distinguish betweendifferent elements. Absence a showing of a specific that the terms“first,” “second,” “third,” etc. connote a specific order, these termsshould not be understood to connote a specific order.

All examples and conditional language recited herein are intended forpedagogical objects to aid the reader in understanding the invention andthe concepts contributed by the inventor to furthering the art, and areto be construed as being without limitation to such specifically recitedexamples and conditions. Although embodiments of the present disclosurehave been described in detail, it should be understood that variouschanges, substitutions, and alterations could be made hereto withoutdeparting from the spirit and scope of the present disclosure.

The previous description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the presentdisclosure. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the disclosure. Thus, the present disclosure is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the principles and novelfeatures disclosed herein.

What is claimed is:
 1. A method comprising: splitting an original tokeninto a first sub-token and a second sub-token; generating a first hashvalue of the first sub-token and a first randomness value; generating asecond hash value of the second sub-token and a second randomness value;evaluating a non-interactive zero knowledge proof regarding the split ofthe original token into the first sub-token and the second sub-token;sampling a first signature key and first verification key associatedwith the first sub-token and a second signature key and secondverification key associated with the second sub-token; generating afirst signed value of a concatenation of the first hash value and thefirst verification key and signed using an initial signature key of acurrent owner of the original token; generating a second signed value ofa concatenation of the second hash value and the second verification keyand signed using the initial signature key of the current owner of theoriginal token; and sending the non-interactive zero knowledge proof,the first hash value, the first signed value, the first verificationkey, the second hash value, the second signed value, and the secondverification key to an administrator of a blockchain for posting to theblockchain.
 2. The method of claim 1, wherein the non-interactive zeroknowledge proof is based on an initial hash of the original token and aninitial randomness value, the first hash value, and the second hashvalue.
 3. The method of claim 1, wherein the first sub-token and thesecond sub-token are a faithful decomposition of the original token. 4.The method of claim 1, wherein the original token includes informationfrom an issuer regarding a manner in which the original token may besplit.
 5. The method of claim 4, wherein the information includes atleast one of a unit of time by which the original token is divisible,and a subset of rights associated with ownership of an asset associatedwith the original token that are divisible from a remainder of therights associated with ownership of the asset.
 6. The method of claim 1,further comprising verifying that the blockchain includes aninvalidation of an original list associated with the original token andthe creation of a first new list associated with the firs sub-token anda second new list associated with the second sub-token.
 7. The method ofclaim 1, further comprising splitting the first sub-token into a thirdsub-token, a fourth sub-token, and a fifth sub-token in a singletransaction, the third sub-token, the fourth sub-token, and the fifthsub-token being a faithful decomposition of the first sub-token.
 8. Themethod of claim 1, wherein the non-interactive zero knowledge proof isdiscarded by the administrator of the blockchain after verification ofthe non-interactive zero knowledge proof.
 9. The method of claim 1,wherein the non-interactive zero knowledge proof is posted to theblockchain.
 10. One or more non-transitory computer-readable mediacontaining instructions that, when executed by one or more processors,cause a system to perform operations, the operations comprising:splitting an original token into a first sub-token and a secondsub-token; generating a first hash value of the first sub-token and afirst randomness value; generating a second hash value of the secondsub-token and a second randomness value; evaluating a non-interactivezero knowledge proof regarding the split of the original token into thefirst sub-token and the second sub-token; sampling a first signature keyand first verification key associated with the first sub-token and asecond signature key and second verification key associated with thesecond sub-token; generating a first signed value of a concatenation ofthe first hash value and the first verification key and signed using aninitial signature key of a current owner of the original token;generating a second signed value of a concatenation of the second hashvalue and the second verification key and signed using the initialsignature key of the current owner of the original token; and sendingthe non-interactive zero knowledge proof, the first hash value, thefirst signed value, the first verification key, the second hash value,the second signed value, and the second verification key to anadministrator of a blockchain for posting to the blockchain.
 11. Thenon-transitory computer-readable media of claim 10, wherein thenon-interactive zero knowledge proof is based on an initial hash of theoriginal token and an initial randomness value, the first hash value,and the second hash value.
 12. The non-transitory computer-readablemedia of claim 10, wherein the first sub-token and the second sub-tokenare a faithful decomposition of the original token.
 13. Thenon-transitory computer-readable media of claim 10, wherein the originaltoken includes information from an issuer regarding a manner in whichthe original token may be split.
 14. The non-transitorycomputer-readable media of claim 13, wherein the information includes atleast one of a unit of time by which the original token is divisible,and a subset of rights associated with ownership of an asset associatedwith the original token that are divisible from a remainder of therights associated with ownership of the asset.
 15. The non-transitorycomputer-readable media of claim 10, the operations further comprisingverifying that the blockchain includes an invalidation of an originallist associated with the original token and the creation of a first newlist associated with the firs sub-token and a second new list associatedwith the second sub-token.
 16. The non-transitory computer-readablemedia of claim 10, the operations further comprising splitting the firstsub-token into a third sub-token, a fourth sub-token, and a fifthsub-token in a single transaction, the third sub-token, the fourthsub-token, and the fifth sub-token being a faithful decomposition of thefirst sub-token.
 17. The non-transitory computer-readable media of claim10, wherein the non-interactive zero knowledge proof is discarded by theadministrator of the blockchain after verification of thenon-interactive zero knowledge proof
 18. The non-transitorycomputer-readable media of claim 10, wherein the non-interactive zeroknowledge proof is posted to the blockchain.
 19. A system, comprising:one or more processors; and one or more non-transitory computer-readablemedia containing instructions that, when executed by the one or moreprocessors, cause the system to perform operations, the operationscomprising: splitting an original token into a first sub-token and asecond sub-token; generating a first hash value of the first sub-tokenand a first randomness value; generating a second hash value of thesecond sub-token and a second randomness value; evaluating anon-interactive zero knowledge proof regarding the split of the originaltoken into the first sub-token and the second sub-token; sampling afirst signature key and first verification key associated with the firstsub-token and a second signature key and second verification keyassociated with the second sub-token; generating a first signed value ofa concatenation of the first hash value and the first verification keyand signed using an initial signature key of a current owner of theoriginal token; generating a second signed value of a concatenation ofthe second hash value and the second verification key and signed usingthe initial signature key of the current owner of the original token;and sending the non-interactive zero knowledge proof, the first hashvalue, the first signed value, the first verification key, the secondhash value, the second signed value, and the second verification key toan administrator of a blockchain for posting to the blockchain.
 20. Thesystem of claim 19, wherein the non-interactive zero knowledge proof isbased on an initial hash of the original token and an initial randomnessvalue, the first hash value, and the second hash value, and the firstsub-token and the second sub-token are a faithful decomposition of theoriginal token.